home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 16330 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.8 KB
  1. Path: news.nyu.edu!schonberg!dewar
  2. From: dewar@cs.nyu.edu (Robert Dewar)
  3. Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.edu
  4. Subject: Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)
  5. Date: 10 Apr 1996 07:33:21 -0400
  6. Organization: Courant Institute of Mathematical Sciences
  7. Message-ID: <dewar.829135457@schonberg>
  8. References: <JSA.96Feb16135027@organon.com> <dewar.829048603@schonberg> <4kdspcINN6ct@keats.ugrad.cs.ubc.ca> <dewar.829079393@schonberg> <4kf5mrINN47r@keats.ugrad.cs.ubc.ca>
  9. NNTP-Posting-Host: schonberg.cs.nyu.edu
  10. X-Newsreader: NN version 6.5.0 (NOV)
  11.  
  12. Kazimir says
  13.  
  14. "Dewar: in the absence of clarity in a standard, as an implementor, follow the
  15. pack. Look at what most implementations do, and stick to the unwritten
  16. standards of the community."
  17.  
  18. That of course completely misunderstands my position and Kazimir's failure
  19. to undertand the central issue here is a great illustration of my central
  20. point. In fact I could not have asked for anyone to make the point 
  21. more clearly.
  22.  
  23. I brought up this thread not as a discussion of proper programming
  24. practices, but of the importance of specs, and to give an example
  25. of portability problems caused by inaccurate specs.
  26.  
  27. Kazimir's view is "so what if the specs are vague, never mind, if people
  28. are "rational" or follow "unwritten rules", then it probably won't matter
  29. much.
  30.  
  31. The trouble is that it absolutely *does* matter, and it matters much!
  32. If programmers continue to follow Kazimir's casual attitude towards
  33. specs, then we continue to get libraries, and, as we see in the case
  34. of POSIX, even standards, that are unacceptably vague.
  35.  
  36. I am not asking for formal specifications, although with library
  37. routines like this it would not be too hard, and would definitely
  38. be useful, but I think people need to have more formal training
  39. in semantics, so that they understand the critical issue of
  40. clear specifications.
  41.  
  42. The bravado attitude of Kazimir and Peter -- "people shouldn't make
  43. errors, if they do they get what they deserve", or "people should
  44. think clearly, real programmers don't need specs [to be fair that
  45. is Kazimir and not Peter]" is actually often more of a menace
  46. than incompetence. I have often seen big programs get into horrible
  47. trouble because a really clever programmer thought that rigorous
  48. engineering could be replaced by programming brilliance.
  49.  
  50. As I have said many times, the details of the read issue are not that
  51. important. It is simply a case where different implementatoins have
  52. subtly different specs, and consquently a program that is semantically
  53. correct in one implmentation is wrong in another. The only cure to this
  54. problem is clear specification at an abstract, implementation-independent
  55. level. People who think that they can overcome the lack of such clear
  56. abstract specifications by guessing what is rational or reasonable
  57. are fooling themselves badly.
  58.  
  59.